A Formal OO Method Inspired by Fusion and Object-Z

We present a new formal OO method, called FOX , which is a synergetic combination of the semi-formal Fusion method and the formal specification language Object-Z. To manage complexity and to foster separation of concerns, FOX distinguishes between analysis and design. In each phase structure and behaviour specifications are developed step-by-step. The specifications may be graphical or textual. We give proof obligations to guarantee that the developed models are formally consistent and complete, and that the resulting system conforms to the original specification. By walking through a simple example – a graph editor – we illustrate the application of FOX . 1 The Need for a Formal OO Method Semi-formal OOA/D methods, such as Booch’s object-oriented design [1] or Rumbaugh’s OMT [20], are widely accepted in practice. Generally, they have a planned procedure; that is, step-by-step the software developer can approach a specific goal. This fact, combined with the support for creating visual appealing, abstract models of required structure and behaviour, makes them so attractive. However, due to their semi-formal nature, the notations of these methods lack a firm semantic basis. Thus, it is difficult to reason about the contents of the produced documents: their formal consistency, completeness, and conformance. For high-integrity systems this lack of imprecision is unacceptable. Such systems need a way to verify the development. Formal methods add the mathematical rigour to the development of these systems. However, their take-up in the real world is still relatively small for several reasons. First, users of formal methods must have a sound mathematical background. Second, formal methods often lack structuring tools for program development in the large. Finally, formal methods often lack a detailed process. The combination of semi-formal OOA/D methods with formal methods has been suggested as a good solution to overcome the aforementioned problems. Lano [15] and Ruiz-Delgado and associates [19] discuss the benefits of this combination at length. The work done by various groups in this new area can be classified as either incorporating object-oriented features (i.e., objects, classes, and inheritance) into a formal method, or as integrating a formal language into a semi-formal OO method. Lano and Haughton [16] give a collection of case studies of the former approach, noteworthy examples of the latter approach are [5,8,12,14]. However, both approaches are not satisfying: Incorporating OO concepts in a formal method does not add the necessary process to develop OO software. Integrating a formal notation into an semi-formal OO method is not adequate because often neither the formal language fits the development paradigm nor the method is adapted to the new potentials for automation or verification, which formal specifications offer. We need a new synergetic combination of both methods with equal rights. The purpose of this paper is to introduce the main features of our new formal object-oriented method FOX . We show which models to build, which steps to take, and which notation to use. Fusion supplies the inspiration of the process and the graphical notation, as formal notation we use Object-Z. The principle contribution of FOX is its process to develop good formal specifications. In particular: – To foster separation of concerns, FOX distinguishes analysis and design. It presents criteria when to stop the analysis, and what to do in the design. – To master complexity, FOX models state and behaviour in complementary views. – To show the system’s static and dynamic architecture, FOX supports visual appealing graphical models as well as textual specifications in Object-Z. – To verify the developed system, FOX defines Object-Z proof obligations for all deliverables. The rest of this section sketches the proposed method and gives an overview of Object-Z. We assume the reader to be familiar with a semi-formal OO method and Z. 1.1 FO X : Overview of the Method FOX is inspired by Fusion, a second generation method advocated by Hewlett Packard [7,17]. FOX is a step-by-step process, which guides a development team from an initial requirements document to the verified design of an OO software system. The method distinguishes analysis, which produces a declarative specification of what the system does, and design, which produces an abstract OO model of how the system realizes the required behaviour. The reuse phase, which considers what classes should be specialized or generalized, and the implementation, which encodes the design in a programming language, is currently not part of the method. Figure 1 gives an overview of the FOX process. Analysis. Starting from a requirements document, the analysis process produces two models, which specify how the system interacts with its environment. An expressive entity-relationship diagram, called analysis class diagram, captures the state of the problem domain and the boundary of the system. The translation into Object-Z defines the semantics of this model. IMPLEMENTATION REQUIREMENTS DOCUMENT DESIGN ANALYSIS STATE MODEL State Schemas Class Diagram BEHAVIOUR MODEL Life-Cycle Diagram Operation Schemas PROGRAM STATE REFINEMENT State Schemas Class Diagram BEHAVIOUR REFINEMENT Object Interaction Diagram Operation Schemas REUSE INHERITANCE REFINEMENT Fig. 1. Overview of the FOX process Object-Z operation schemas working on the system’s state describe the behaviour of the system operations. A variant of statecharts defines the allowable sequences of system operations, that is the system’s life-cycle. After the construction of the analysis models, the developer must validate them against the requirements and must check them for formal completeness and consistency. Design. The design process uses the analysis models and produces two further models describing how the state and the behaviour is refined. A set of refined domain, controller, interface, and toolkit classes, expressed graphically in the design class diagram, represents the state. The interaction of individual objects, specified using operation schemas supplemented by object interaction diagrams, realizes the required behaviour. After construction of the design models, the user must check whether the design conforms to the analysis. FOX adopts the principal process as well as several of its notations from Fusion. However, it differs from Fusion in the following respects. First, we extend Fusion’s notations and give them a transformational semantics. Second, due to the use of Object-Z, we can prove internal completeness, consistency, and conformance of FOX ’s models. Third, we change the design process and its notations: Whereas Fusion’s process is driven by the development of object-interactions, FOX considers state and behaviour refinement as two interacting steps with equal rights. The basic notations and process steps of FOX can be illustrated most effectively by walking through a simple example. We will consider a small drawing application, which allows the user to draw lines and boxes, and to move them. This example is necessarily simple. The point is to illustrate each step and the modelling notation of the FOX analysis and design phase. Section 2 and 3 presents the development of this example in depth. 1.2 Object-Z: Extensions from Z FOX uses as its formal notation Object-Z [10,11]. The major extension from Z [23] to Object-Z is the class schema, which encapsulates a single state schema and all operations that may affect its variables. The class schema is not only a syntactic extension, but also defines a type whose instances are object-references. The specification of an object-oriented system consists of a number of named classes, which might stand in multiple inheritance relation. In this paper, the basic structure of a class is as follows: ClassName[generic parameters] inherited class designators type and constant definitions primary variables ∆ derived variables